home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16375 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.1 KB
  1. Path: galaxy.ucr.edu!not-for-mail
  2. From: thp@cs.ucr.edu (Tom Payne)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Followup-To: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  6. Date: 10 Apr 1996 16:10:06 GMT
  7. Organization: University of California, Riverside
  8. Message-ID: <4kgmgu$jm@galaxy.ucr.edu>
  9. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <4kbrt5$k3h@mulga.cs.mu.OZ.AU> <4kcer3$mi4@solutions.solon.com> <4kdnvq$3n8@mulga.cs.mu.OZ.AU>
  10. NNTP-Posting-Host: corvette.ucr.edu
  11. X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
  12.  
  13. Fergus Henderson (fjh@mundook.cs.mu.OZ.AU) wrote:
  14. : seebs@solutions.solon.com (Peter Seebach) writes:
  15. [...]
  16. : >Further, that behavior is a flat out bug; it is never correct, and the
  17. : >portability problem lies in the program, not the language spec.  The
  18. : >program needs to be fixed.
  19. : 
  20. : No, the portability problem is the different behaviour of the program,
  21. : when run on different systems.  It does not "lie in" the program -- it
  22. : makes little sense to speak of behaviour "lying in" a program.  The
  23. : behaviour is not something that has a single cause -- rather, it has a
  24. : multitude of causes, some direct, and some indirect.  The problem is
  25. : caused by the program AND by the implementation AND by the language spec.
  26.  
  27. At the risk of mentioning the obvious, when the standard leaves a
  28. behavior "undefined", it increases the portability of the langauge
  29. (i.e., the ease of generating efficient object code on a large range
  30. of architectures) at the expense of portability of programs written in
  31. that language (i.e., same behavior under different implementations).
  32. "Undefined behavior" takes the implementors off the hook in many
  33. difficult situations and give them more control in others.  Their life
  34. is made more comfortable at the expense of the programmer, who looses
  35. control and the ability to know what to expect in certain circumstances.  
  36.  
  37. Implementors are well represented in the C and C++ committees and the
  38. balance of power is reflected in the standards these groups have 
  39. generated.  Ada by contrast was developed under the auspices of the
  40. U.S. government's Department of Defense, a customer, not a vendor,
  41. of progrmming language implementations.  I've not read the Ada 
  42. standard but I'd expect the balance of power to be reflected in far
  43. less "undefined behavior."
  44.  
  45. The problem shows up in real situations: In C++ AFAIK there is no
  46. efficient way for an exception at the hardware level to generate an
  47. exception (in the C++ sense) on the part of the running program -- the
  48. running must poll a volatile atomic variable to see if the exception
  49. has occurred.  This obviously makes the langauge, as defined in the
  50. standard, unacceptable for use in the area of, say, embedded systems.
  51. Even in scientific progrmming, however, one would like to be able to
  52. throw an exception out of a matrix manipulation routine when the
  53. underlying hardware detects a floating point exception, and polling
  54. for such an occurrence would involve unacceptable overhead.
  55.  
  56. Tom Payne (thp@cs.ucr.edu)
  57.  
  58.  
  59.  
  60.